Chapitre 2 Étapes du projet dans l’ordre chronologique

2.1 Mise en place

2.2 Le cycle de développement DevOps

Chaque demande du comité éditorial sera listée dans un ou plusieurs tickets. Chaque développeur qui prend en charge un ticket fera valider ses développements par un responsable du développement, puis le résultat par le comité éditorial avant de pouvoir fermer ce ticket. D’une manière générale, pour une production avec R, la validation concerne (1) l’apparence générale de la production (hors contenu pertinent), (2) le contenu (non mis en forme), et (3) le contenu intégré dans le moyen de production. Dans le cadre d’une publication PROPRE, la validation concerne les outils d’aide à la création de contenu.

Le produit de développement est toujours un package R, documenté, testé et versionné. Le produit final visé est une publication reproductible créée à partir de ce package. Les étapes de mise en place doivent avoir permis de séparer la publication en différents chapitres, si possible indépendants. La publication sera construite en plusieurs étapes, répétées pour chaque chapitre.

  1. UI first : Création et validation de l’apparence du futur produit (bookdown, sans contenu) et de la façon de le construire par les utilisateurs (Comment apparaît le menu de création de la publication).

  2. Rmd then :

    • [dev] : Création des vignettes du package. Plutôt dédiées à la documentation du développement, elles présentent l’utilisation directe des fonctions créées. Les vignettes compilées seront présentées sur un site web pour validation du contenu et des traitements des données par le comité éditorial [Ed].
    • [edition] : Création du contenu des textes de la publication. Les titres et paragraphes sont validés en comité éditorial. En théorie, il ne devrait pas y avoir de discussion sur la structure du chapitre à ce stade.
  3. Documentation utilisateurs. C’est une extension de la partie Rmd then qui doit expliquer aux utilisateurs du produit comment l’utiliser. Cela inclut

  4. Integration du contenu dans le produit. Lors de cette phase, il ne devrait plus y avoir de discussion ni sur l’apparence, ni sur le contenu, ni sur le fond. Les codes R sont figés. Il s’agit surtout de vérifier que tout se passe bien dans le produit final.

Les 1., 2. et 3. peuvent se faire indépendamment, en parallèle. Le 4. se fait à la fin. Ce peut être la fin de la validation d’un chapitre en particulier. Mais pas d’un paragraphe.

Les guides nécessaires à la bonne réalisation des cycles de développements sont les suivants :

2.3 Tests utilisateurs et livraisons

À l’issue d’un cycle, le contenu est figé, les développements de nouvelles fonctionnalités sont figés. On entre dans une phase de validation. Les équipes de développement et d’édition testent le bon fonctionnement des outils